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Abstract 

This  paper  will  address  the  important  role  of  architecture  planning  for  ensuring  system  interoperability  in 
a  network-centric  coalition  environment.  As  US  forces  become  more  dependent  upon  coalition  partners 
to  support  crises  around  the  globe,  systems  interoperability  becomes  a  major  concern.  This  problem  is 
more  acute  in  the  Pacific  theater,  where  the  US  has  no  equivalent  to  NATO  to  address  such  issues.  In  the 
Pacific,  the  US  has  numerous  bilateral  agreements  with  allied  nations  and  as  such  the  degree  of 
interoperability  varies  from  country  to  country.  A  key  to  understanding  interoperability  shortfalls  is 
documenting  the  “as  is”  architecture  for  each  primary  allied  nation  to  facilitate  identification  of  key 
information  exchange  requirements  for  critical  command  and  control  nodes. 

The  importance  of  enterprise  architecture  planning  should  not  be  downplayed.  Enterprise  architecture 
planning  considers  both  the  tactical  and  strategic  need  for  information  exchange  in  supporting  the 
organization’s  mission  [Spewak  92].  This  is  especially  true  with  the  plethora  of  C4ISR  systems  scattered 
throughout  the  US  Pacific  Command  (USPACOM)  theater  of  operations  where  access  to  secure,  quality 
data  is  vital  to  ongoing  operations. 

Headquarters  (HQ)  US  Pacific  Command  (USPACOM)  recognized  the  need  for  documenting  baseline 
architectures  with  the  publication  of  US  Commander  in  Chief,  Pacific  (USCINCPAC)  Instruction  2010-4 
[USCINCPACINST  2010-4].  This  instruction  provided  guidance  to  component  commands  on  how  to 
describe  and  construct  systems  and  operational  architectures.  The  Joint  Forces  Program  Office  was  asked 
to  assist  with  this  effort  at  Alaska  Command  (ALCOM)  in  the  fall  of  1999.  The  ALCOM  architecture 
study,  using  a  prototype  version  of  the  Joint  C4I  Architecture  Planning  System  (JCAPS),  illustrated  the 
utility  of  having  a  clearer  picture  of  the  enterprise  architecture  described  in  common  lexicon.  With  this 
information,  the  CIO  can  make  more  informed  decisions  concerning  resource  requirements  and 
contingency  planning,  to  ensure  information  technology  adequately  supports  Alaskan  Command’s 
mission  threads. 

Another  result  of  the  Alaskan  Command  study  was  the  need  to  consolidate  the  numerous  architectures 
that  have  been  developed  in  recent  years.  Documentation  of  various  architectures  already  exist  to  some 
extent— having  been  produced  by  the  Intelligence  Directorate  (J2),  the  Operations  Directorate  (J3),  the 
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Communications  Directorate  (J6)  and  other  supporting  organizations.  These  independent,  non- 
collaborative  efforts  have  resulted  in  information  resources  that  often  are  of  little  use  and  are, 
consequently,  shelfware.  During  a  survey  at  HQ  USPACOM  conducted  by  a  CINC  Interoperability  / 
Joint  Forces  Program  Office  team  on  1  March  2000,  approximately  sixteen  documented  or  ongoing 
architecture  efforts  were  revealed  across  the  J2,  J3,  and  J6.  Each  effort  is  separate  and  distinct.  No 
centralized  data  repository  exists.  The  existence  of  a  relational  architecture  database  that  could  be  easily 
updated,  maintained  and  reused  would  reduce  repeated  duplication  of  efforts  and  multiple  data  requests 
and  improve  contingency  and  resource  planning  and  allocations. 

What  are  the  implications  of  understanding  the  Enterprise  Architecture  for  Joint/Coalition 
interoperability?  Enterprise  architecture  provides  a  top-level  model  of  how  information  flows  across  the 
organizations  within  the  enterprise  domain.  It  identifies  the  key  nodes,  potential  constraints,  and  may 
identify  duplication  of  efforts.  It  is  a  cornerstone  to  integrating  or  updating  technologies  and 
understanding  what  data  is  needed  where  and  when.  [Spewak  92] 

This  paper  will  discuss  the  application  of  commercial  best  practices  into  the  development  of  military 
C4ISR  architectures  and  the  effective  consolidation  of  existing  C4ISR  architectures. 

The  Challenge 

Since  the  end  of  the  Cold  War,  there  has  been  a  significant  reduction  in  the  ranks  of  the  US  military.  US 
presence  overseas  has  also  been  greatly  reduced.  Yet,  the  operations  tempo  has  increased  during  the  last 
decade  with  the  US  involved  in  numerous  peacekeeping  missions  and  humanitarian  and  regional 
conflicts.  These  joint  operations  have  also  included  allies  and  coalition  partners.  In  today’s  environment, 
with  US  forces  stretched  thin,  any  crisis  will  demand  US  and  Allied  coalitions.  Recent  coalition 
operations  have  revealed  interoperability  shortfalls  and  lack  of  C4ISR  and  logistic  systems  synergies. 
These  shortfalls  impede  the  ability  of  joint  US  and  coalition  warriors  to  effectively  and  efficiently  use  all 
available  information  systems  to  perform  the  assigned  missions,  be  they  major  regional  conflicts, 
peacekeeping  missions  or  humanitarian  relief.  Some  suggest  that  the  US  work  their  own  inter-service 
interoperability  challenges  first  and  foremost  before  engaging  with  its  principle  allies.  This  would  be  a 
serious  mistake.  Working  US  interoperability  issues  without  addressing  principal  Allied  force 
interoperability  would  only  further  exacerbate  the  capabilities  gap.  In  order  to  understand  the  magnitude 
of  the  interoperability  issues,  consider  viewing  the  C4ISR  domain  in  terms  of  the  enterprise  architecture. 

Enterprise  Architecture 

What  is  enterprise  architecture?  The  DoD  C4ISR  Architecture  Framework  document  describes 
architecture  as  a  “mechanism  for  understanding  and  managing  complexity.”  [C4ISR  97]  David  Sims  of 
SharpAngle.Com,  states,  “Enterprise  architecture  provides  the  underlying  framework,  which  defines  and 
describes  the  platform  required  by  the  enterprise  to  attain  its  objectives  and  achieve  its  vision.”  [Sims  00] 
The  enterprise  architecture  consists  of  four  interrelated  views:  Information,  Business,  Application,  and 
Technology. 

The  information  architecture  consists  of  data  models  and  databases  that  serve  all  that  have  access  within 
the  business  domain.  This  suggests  a  universal  common  database  exists  that  is  the  shared,  distributed, 
accurate,  and  consistent  data  resource.  The  data  providers  of  this  repository  ensure  the  quality  of  the 
information  made  available. 

The  business  architecture  represents  the  business  processes.  In  a  military  vernacular,  the  business 
architecture  describes  the  operational  functions  or  what  activities  or  tasks  must  be  performed.  Roger 
Founier  of  Information  Week  describes  the  application  architecture  as  the  core  business  applications 
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required  to  enable  business  process  to  successfully  run  the  business  enterprise  [Sims  00].  It  also  assesses 
the  health  of  current  applications  and  forecasts  new  ones  to  satisfy  future  business  needs. 

The  technology  architecture  describes  the  hardware  platforms  which  link  up  the  application,  business  and 
information  architectures  to  provide  interoperable  systems  that  meets  the  needs  of  the  users  through  out 
the  business  domain. 

The  META  Group  has  projected  that  architecture  enterprise  planning  and  analysis  is  a  growth  industry. 
Their  forecast  in  this  discipline  includes  the  following: 

Through  2005,  the  primary  business  drivers  for  enterprise  architecture  will  be:  1 )  right 
sourcing  business  components  via  disaggregation  ...( i.e.,  corporate  agility);  2)  delivering 
customer  intimacy  and  erecting  exit  barriers  within  a  customer  life-cycle  management 
strategy;  and  3)  driving  information  value  creation  [Meta  00]. 

The  problem  of  network  aggregation/deaggregation  is  one  that  parallels  the  military  need  for  rapidly 
changing  command  organizations  that  can  add  or  subtract  command  levels  based  on  the  current  situation. 
For  a  detailed  discussion  of  the  aggregation/deaggregation  problem,  see  [Hamilton,  Nash  and  Pooch  97]. 

Results  of  the  US  Alaskan  Command  Architecture  Effort 

When  discussing  enterprise  architecture,  it  is  instructive  to  consider  what  can  be  learned  by  actually 
constructing  an  architecture.  In  late  1999,  the  Joint  Forces  Program  Office  undertook  the  construction  of 
a  baseline,  “as-is”  architecture  at  US  Alaskan  Command  (USALCOM).  This  project  supported  both 
USPACOM,  as  the  first  project  to  attempt  execution  of  their  new  architecture  generation  instruction 
[USCINCPACINST  2010-4];  and  US  Joint  Forces  Command  (USJFCOM),  who  was  interested  in  the 
feasibility  of  theatre  architecture  development.  Among  other  goals,  the  project  provided  a  “live -fire  test” 
for  the  then-current  prototype  of  the  Joint  C4I  Architecture  Planning  System  (JCAPS)  tool. 

This  effort  was  very  carefully  scoped,  to  include  only  the  systems  in  the  USAFCOM  headquarters  -  about 
100  systems.  Despite  this  limited  scope,  the  effort  took  around  2100  staff-hours  -  more  than  a  full  staff 
year  -  to  complete.  A  closer  examination  of  how  the  time  was  spent  will  show  some  clear  benefits  to  an 
enterprise  architecture  approach.  The  methodology  that  was  followed  is  shown  in  Figure  1,  with  the 
number  of  staff -hours  spent  on  each  task  in  the  lower  right  hand  corner  of  each  block. 


Figure  1.  AFCOM  Architecture  Methodology  and  Levels  of  Effort 
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First,  the  review  of  existing  documentation  and  the  data  gathering  took  almost  750  staff-hours.  This 
extremely  laborious  and  time  consuming  process  included  collection  and  review  of  fragmented, 
uncorrelated,  uncoordinated  depictions  of  system  connectivity  for  the  system  views,  as  well  as  interviews 
of  operators  about  how  they  accomplished  their  missions  for  the  operational  views.  Considering  the  large 
amount  of  time  invested  in  this  step,  it  is  no  wonder  that  architectures  have  been  difficult  to  document. 

An  enterprise  approach  to  architecture  planning  would  help  mitigate  this  level  of  effort.  By  integrating 
the  collection  and  maintenance  of  architectural  information  into  existing  business  processes,  the  experts’ 
knowledge  can  be  captured  in  a  way  that  is  usable  not  just  by  them,  but  by  others.  Rather  than  having  a 
specialized  “architecture”  group  gather  data  from  the  experts,  the  experts  themselves  can  maintain  the 
data.  By  providing  a  uniform  tool  for  this  across  the  enterprise,  experts  can  team  and  share  knowledge 
more  effectively.  This  might  ultimately  result  in  a  reduction  in  effort  across  the  organization  by  making 
key  information  more  readily  accessible  -  in  contrast  to  the  high  cost  of  collection  observed  when  the 
generation  of  the  architecture  was  completely  decoupled  from  the  business  process. 

Another  key  indicator  in  terms  of  level-of-effort  was  the  amount  of  time  required  to  perform  data 
correlation.  Multiple  data  sources  had  to  be  reconciled  and  fused  in  order  to  produce  a  coherent, 
consistent  set  of  architectural  data.  This  process,  including  the  development  of  a  lightweight  tool  to 
support  it,  took  nearly  400  staff  hours.  There  are  several  systemic  issues  that  lead  to  such  a  high  cost  here 
-  the  existence  of  overlapping  and  uncoordinated  data  sources  was  only  aggravated  by  the  absence  of 
common  terms  of  reference  and  means  of  representation.  Not  only  were  there  multiple  sources  of  data 
(which  did  not  necessarily  agree  on  what  they  said),  but  the  sources  each  said  the  same  things  in  different 
ways.  Even  when  they  were  in  agreement,  the  data  would  often  have  to  be  repackaged  into  a  form  that 
would  be  consistent  across  the  enterprise. 

We  can  examine  how  an  enterprise  approach  to  architecture  might  have  reduced  some  of  this  cost.  Rather 
than  generating  several  sets  of  node  connectivity  diagrams  in  several  different  applications  for  different 
puiposes,  all  node  connectivity  data  would  be  captured  in  the  same  data  source.  By  understanding  how 
the  organization  would  use  this  sort  of  data  -  the  elusive  “so  what?”  of  architecture  -  the  right  data  can  be 
captured.  An  agreement  across  the  organization  can  be  reached  that  will  allow  data  compiled  by  different 
users  to  be  used  together  to  make  decisions,  without  having  to  go  through  the  time-consuming  and 
complex  cost  of  comparing  data  that  is  represented  differently.  Thus,  the  investment  in  standardization  at 
the  enterprise  level  pays  off  by  allowing  the  organization  to  leverage  the  data  embedded  throughout  the 
organization. 

Finally,  we  can  consider  the  amount  of  time  constructing  products.  As  summarized  in  Figure  2,  two  sets 
of  products  were  generated  in  this  effort  -  one  in  JCAPS  and  another  in  PowerPoint.  A  significant 
amount  of  time  was  spent  in  product  generation  after  the  data  had  been  entered.  It  took  nearly  300  staff- 
hours  to  generate  the  PowerPoint  products,  and  while  the  time  required  to  generate  the  JCAPS  products 
from  the  data  was  less  -  about  170  staff-hours  -  the  generation  of  these  products  was  made  somewhat 
easier  by  the  presence  of  the  first  set.  It  is  hoped  that,  in  the  future,  better  tools  can  reduce  this  time. 

Again,  however,  we  see  a  clear  advantage  to  employing  an  enterprise  architecture  strategy.  This  effort 
was  geared  toward  producing  the  products  specified  in  the  USCINCPAC  instruction,  rather  than 
contributing  to  a  shared,  dynamic  enterprise  architecture.  By  embedding  the  data  and  the  use  of  that  data 
into  the  business  processes  of  the  organization,  the  demand  for  (static)  products  is  reduced,  if  not 
eliminated. 
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Figure  2.  Architecture  products  for  Framework  2.0  supported  by  JCAPS  Version  2.0  R14 

Ultimately,  the  investment  in  architecture  development  must  yield  returns  if  it  is  to  be  continued 
throughout  the  enterprise.  Looking  through  the  perfect  lens  of  hindsight  at  the  architecture  developed  for 
USALCOM,  we  see  that  its  utility  is  directly  related  to  a  set  of  well-defined  goals  or  objectives  for  the  use 
of  the  architecture.  Perhaps  the  most  important  lesson  learned  from  the  ALCOM  effort  was  that  these 
goals  must  come  first  and  be  used  to  drive  what  data  is  collected.  A  clear  understanding  of  the  need  for 
and  uses  of  an  architecture  is  required  in  order  to  ensure  a  favorable  return  on  investment.  In  a  nutshell, 
this  is  the  purpose  of  the  enterprise  architecture  strategy. 

Architecture  Consolidation: 

During  the  ALCOM  Architecture  outbrief  to  the  USPACOM  J6,  it  was  suggested  that  all  of  HQ 
USPACOM’s  architecture  data  should  reside  in  one  repository  (the  “Holy  Grail”  as  then-USPACOM-J6 
BG  Byran  described  it)  in  order  that  the  data  can  be  readily  accessed,  centrally  managed,  updated  and 
reused.  In  order  to  determine  the  organization’s  “as-is”  architecture  baseline,  one  should  consider 
collecting,  deconflicting,  and  normalizing  all  existing  architecture  data  that  has  been  accomplished 
previously. 
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Various  architectures  already  exist  to  some  extent— having  been  produced  by  J2,  J3,  J6  and  other 
supporting  organizations.  These  independent,  non-collaborative  efforts  have  resulted  in  information 
resources  that  often  are  of  little  use  and  are  consequently  shelfware.  A  cursory  review  during  the  1  Mar 
2000  visit  to  HQ  USPACOM  by  the  CINC  Interoperability  /  Joint  Program  Office  team  revealed 
approximately  16  documented  or  ongoing  architecture  efforts  across  the  J2,  J3,  and  J6.  Each  effort  is 
separate  and  distinct.  No  centralized  data  repository  exists  for  the  data  collected.  A  relational 
architecture  database  that  can  be  easily  updated,  maintained  and  reused  would  reduce  repeated  duplication 
of  efforts  and  multiple  data  requests  and  improve  resource  planning  and  allocations.  A  proposed 
methodology  for  executing  architecture  consolidation  in  the  JCAPS  relational  database  is  shown  in  Figure 
3. 
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Figure  3.  Proposed  Methodology  for  Executing  Architecture  Consolidation  in  JCAPS. 

In  addition,  by  consolidating  existing  architecture  data,  a  clearly  defined  enterprise  architecture  advances 
C2  capability  through  enhanced  integration  of  C4ISR  architectures.  This  in  turn  promotes  alignment  of 
Joint  and  Service  force  modernization  initiatives  with  concept  of  operations  and  joint  war  fighting 
doctrine.  Consolidating  existing  architectures  also  provides  a  vehicle  to  highlight  potential 
interoperability  shortfalls  within  the  enterprise  domain. 

Developing  the  enterprise  architecture  is  no  small  task.  Ample  resources  should  be  made  available  for 
such  an  undertaking,  as  well  as  strong  management  support  [Spewak  92],  Consolidation  of  existing 
architecture  data  is  the  cornerstone  to  developing  the  enterprise  architecture.  Consolidation  and 
integration  of  existing  and  ongoing  C4ISR  architecture  efforts  into  a  single  reusable  and  maintainable 
data  repository  can  be  accomplished  in  three  steps.  First,  decompose  existing  architectural  threads  into 
constituent  objects.  Then,  deconflict  instances  of  objects  within  each  class,  predicated  upon  a 
configuration  management  and  confliction  resolution  process.  This  is  the  most  tedious  part  of  the 
consolidation  activity,  as  it  requires  much  analysis  and  is  database-query-intensive.  Third,  reconstruct  the 
architectural  thread  using  normalized  objects.  This  is  the  result  of  the  deconfliction  process  as  shown  in 
Figure  4.  A  configuration  control  and  maintenance  process  is  required  to  ensure  data  integrity  upon 
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completion  of  consolidation  efforts.  This  task  may  be  delegated  based  on  the  data  owner,  type,  location, 
organization  or  any  combination  thereof.  [Manley  00] 


Deconflict 

Figure  4.  Architecture  Consolidation  Methodology  [Manley  00]. 

By  consolidating  the  existing  architecture  data,  a  collective  understanding  of  what  is  "built  to  date”  is 
established.  This  will  illuminate  areas  that  require  further  development  within  the  enterprise  domain  and 
provide  a  launching  point  for  assessing  baseline  requirements  through  gap  analysis.  The  organization, 
then,  can  prioritize  follow-on  efforts  to  fill  in  the  architecture  gaps.  The  impact  in  a  joint  coalition 
environment  is  profound.  Understanding  the  enterprise  architecture  is  vital  to  coalition  forces  ability  to 
effectively  operate  in  a  plug  and  play  environment. 

Implications  For  Coalition  Interoperability 

C4ISR  architecture  development  and  implementation  is  complicated  when  the  systems  belong  to  different 
services  and  nations.  Combined  interoperability  -  that  is,  interoperability  between  different  services  from 
different  nations  -  is  challenging.  Sustained  interoperability  cuts  across  two  dimensions:  laterally 
between  countries  and  horizontally  over  time.  The  essential  starting  point  for  combined  C4  planners  is 
the  existing  communications  architecture.  Common  architecture  formats  greatly  expedite  combined  C4 
planning.  This  is  particularly  obvious  in  operational  architecture  planning  for  US  Forces,  and  there  is  no 
reason  to  think  that  resolving  differing  architecture  formats  would  be  any  easier  in  a  combined  operation. 

Conclusions. 

In  this  paper,  the  authors  have  outlined  a  practical  strategy  for  consolidating  existing  C4ISR  architectures. 
Using  our  practical  architectural  success  in  the  US  Alaskan  Command,  we  suggest  that  this  methodology 
can  be  applied  across  large,  combined,  theaters  of  operation.  Our  recommendation  to  USPACOM  is  to 
evaluate  this  premise  by  implementing  an  enterprise  architecture  with  a  coalition  partner.  We  envision 
such  an  evaluation  to  be  a  JCAPS-based  effort  similar  in  size  and  scope  to  the  US  Alaska  Command 
architecture  effort.  Such  a  development  would  provide  practical  coalition  C4  architecture  planning 
benchmarks. 
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